Networks are widely used to connect computer systems to each other. Computer systems execute one or more processes. Those processes typically implement components of software “applications.” For the purpose of explanation, the computer system or device that is executing a particular process or application shall be referred to as the “host” of that process or application.
In some arrangements, the applications are equals, called “peers,” which perform the same functions and which mutually control communications among themselves. In a widely used alternative arrangement, an application running on one host, such as a personal computer or handheld device, is called a client process. The client process requests services from another application called a server process. The server process is often executing on a different host or hosts that have substantially more computing power than the device on which the client is executing.
The term “client” is often used to refer to either the client process (software) or the host (software/hardware) for the client process. To avoid confusion, the term “client” shall be used herein to refer to the host unless otherwise indicated. Similarly, the term “server” is often used to refer to either the server process (software) or the host (software/hardware) for the server process. To avoid confusion, the term “server” shall be used herein to refer to the host unless otherwise indicated.
Organizations providing one or more services on one or more servers may not want to provide the same service to every user of every client making a request. For example, some resources may be intended only for persons associated with the organization and not for the general public.
One solution for preventing access to a resource by a user of a client process who is not an intended user is an authentication mechanism built into the server process. The authentication mechanism challenges the user of the client process to enter a user identification and password. If the user provides the correct identification and password, the user's client is allowed to access the resources provided by the server process. If not, the user's client is denied access.
One problem with this approach is that a particular server may host several server processes, and the authentication process may have to be built into each one. If an authentication process becomes out of date, for example because an authorized user has left the organization, the changes have to be made at all the authentication processes.
Another problem with this approach is that the response is very unsophisticated, providing a simple two-state, “yes” or “no” response. Either the user of the client process is who the user claims to be and is allowed access to all resources provided by the server process; or the user is not, and is denied access to all resources. This is not always satisfactory. An organization providing the server may want the client processes of some users to be denied access, some to be given access to some resources, and others to be given access to other resources. A process providing such multi-valued responses is called “authorization.” For example, a hardware retailer may want to authorize no documentation for some users, marketing materials for other users, user documentation for existing customers, and detailed specifications for technicians troubleshooting equipment in the field. Different users have different authorizations.
One solution for providing an array of different response to multiple requests for the same resource is to use plug-in modules that can be executed on the servers and that can be customized to provide particular behavior by the server processes.
One problem with this approach is that the plug-in modules are managed separately on each host on which it is installed. If an organization has connected several hosts to the network to handle the number of requests expected, the plug-in module has to be installed on each host. The different hosts may be different platforms that use different combinations of hardware and operating systems. In such circumstance, the plug-in module and installation process might have to be modified for each platform combination. In addition, every time the behavior is modified, changes have to be made for each platform, and the appropriate changes have to be installed on each host. Maintaining consistent behavior across multiple hosts acting as servers becomes burdensome and prone to error.
Another problem with conventional plug-in modules is that one plug-in module handles all requests for all resources at each server. Therefore, to provide individualized response to each request, the module can become exceedingly complex and computationally intense. In many instances, the module is kept manageable by limiting the number of different responses.
The problem of complex modules is exacerbated because some plug-in modules are implemented so that a separate instance of the module is executed for each request received by each server. For services that are intended to be provided to hundreds and thousands of clients, computational resources consumed by hundreds or thousands of instances of complex plug-in modules can be excessive and accelerate the degradation of performance observed at the servers with increasing numbers of clients.
Furthermore, many plug-in modules can only be changed by removing the active plug-in module through commands manually issued at the server, and inserting the new plug-in module through additional commands manually issued at the server. This sequence of commands makes both versions of the plug-in module unavailable for a period of time during the change. Making both versions of the plug-in module unavailable for a time essentially takes the behavior provided by the plug-in modules offline for a while, producing a gap in the behavior offered by the plug-in modules. Sometimes the server application itself, or an entire suite of server applications using the plug-in module, becomes unavailable during the change of plug-in modules, rendering the server unresponsive for a period of time. Such a gap in behavior is often unacceptable on a server that receives requests at a high rate for most times of the day.
Based on the preceding description, there is a clear need for customized responses to requests for resources that alleviate or avoid these problems.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.